An online synchronized content management system, such as Dropbox® from Dropbox Inc. of San Francisco, Calif., allows its users to store and synchronize data on a cloud-based storage and across multiple client devices. Thus, for example, a user may upload a personal folder to the content management system, and then share the folder on multiple user devices by making duplicate copies of the folder on each of the devices. The instances of the shared folder, though may be residing on different devices, can be kept synchronized. In other words, through the process of synchronization, the contents of the shared folder on multiple client devices can be kept identical. Even the slightest modification made by the user to one of the instances of the folder can automatically be replicated in other instances of the folder in a matter of seconds.
However, data synchronization across multiple client devices has traditionally been handled by a central server such as the content management system. More specifically, a change in content of a shared folder on one client device would be first replicated in the instance of the folder stored in the central content management system. The central server would then synchronize the shared folder with every other client device. Although this method of data synchronization may be relatively straightforward and intuitive to implement, it has several drawbacks.
First, too much burden may be placed on the central distributor. In other words, since every single client device must rely on the content management system to perform the task of data distribution, the content management system must bear the brunt of the workload. As such, the content management may become overburdened to handle an excessive amount of data processing and an overwhelming amount of data transfers. Second, the stability and robustness of the system can be compromised. Since every data synchronization job needs to go through the central distributor, the entire system can be paralyzed if the central distributor suddenly becomes unavailable. Third, connecting to and communicating with the central distributor can be costly. Client devices often need to connect to the central server via a wide area network (WAN) such as the Internet. Wide area networks can be, in general, less reliable and of inferior performance than a local area network (LAN).
Accordingly, some content management systems, such as Dropbox®, allow their client devices or peers to synchronize with each other, especially over a LAN. Synchronizing data over a LAN connection (also called a “LAN sync”) may confer several benefits over synchronizing through a central distributor. Due to the relatively smaller geographical area that a typical LAN occupies, a LAN generally offers better performance and reliability than a WAN. A LAN, in general, can also be more configurable and customizable. Moreover, communicating over a LAN may be more cost-effective because there is no need to pay additional bandwidth or subscription fees for Internet communication.
However, in order for a client device to synchronize with another client device over a LAN, the client device needs to know which other client devices may be available for communication on the local network and which shared files or folders may be available for synchronization on each of those client devices. In other words, clients may want to find other clients on the same local network that contain the same files or folders. One way to obtain such information is for each client device to broadcast messages out to the local network to solicit information about other client devices' file-sharing availability. Sometimes each client device on the local network may voluntarily announce its shared files and folders by broadcasting a list of shared files and folders, thereby allowing other clients on the network to assemble a full list of available files and folders in the local network.
Sending broadcast messages out to the local network, however, can quickly flood the pipeline. This problem can be further compounded when the number of content items to be synchronized and/or the number of client devices sending out broadcast messages is large, because the amount of generated traffic can become noisy and may even overwhelm the network. Moreover, it cannot be guaranteed that a broadcast message would indeed reach every other host residing in the local network. For instance, if the network is subdivided into one or more subnetworks which map to specific departments or buildings, the broadcast message might not be able to travel beyond the relevant subnet boundary. Other impediments such as an internal firewall can further limit the broadcast message's reach. In other cases, the local network administrator or the network policy may prevent the local network nodes from sending out a massive amount of unsolicited broadcast messages. Broadcasting information about the shared files or folders may also raise security and privacy concerns.